Run a Risk Check

Run a risk check for requested traffic.

Note: Risk calculations are defined by the tuple in the risk check request (riskCheckRequest) and NOT the device rules.

Tip: Zone calculations

Network zones are used in the risk calculations performed by this API when applying the request parameters device (device) and risk profile (riskprofile) as follows:

  • device (device) optional

    When you include a device in the request, zones are taken from the last analysis performed on the it. (The risk profile property (riskprofile) in this case is not applied in the zone calculation).

    Note: The device must have at least one report.

  • risk profile (riskprofile)

    When you DO NOT specify a device in the request, network zones are used for the risk calculations in the following manner:

    • Using Standard profile: Private IPs (as defined in RFC1918) are defined as internal zone. All other IPs are defined as external zone.

    • Using a custom risk profile: IPs of the network hostgroups specified in the risk profile are defined as internal zone. All other IPs are defined as external zone.

This API can be used for the following Risk Types:

Risk type

Explanation

Traffic Queries - Relates to risks regarding traffic allowed through the device 

D Between internal networks

I

From external networks to internal networks

O

From internal networks to external networks

U

User defined risks may be also returned by API: as long as the risk is similar to the supported risk types (D, I, O, C, and R)

C Risk with specific IP addresses

Rules - Relates to risks regarding rule definitions.

R

Rule definition

Note:

  • When a device is not specified in the request, risks which include DMZ are not supported:
    J
    - from internal networks to DMZ, Z - from DMZ to internal networks, K - between DMZs, M - from DMZ to external networks.

  • By design the API will not return risks that are specific to device brand, such as  F - access to Firewall or P - device properties.

For a detailed list of risk types, see Advanced risk editing.

Resource Name: /api/v1/riskcheck/calculate

Request Method: POST

Request Query Parameters:

Element

Type

Description

riskprofile

Mandatory

String

Risk profile for risk calculation. 2 options:

  1. Standard
  2. Risk profile name in format: [name].xml. For example, RiskProfile1.xml

Request Body Parameters:

Element

Type

Description

device

optional

string

When you include a device in the request, zones used in the the risk calculation are taken from the last analysis performed on the it. Use the device tree name

Note: Risk calculations are defined by the tuple in the risk check request (riskCheckRequest) and NOT the device rules.

riskCheckRequest

mandatory

array of requested traffic tuples entity

Each tuple consists of:

  • id optional numeric Traffic ID
  • destination mandatory: array of strings, accepts wildcard * for any, one or more IPs and IP ranges (comma separated)
  • service mandatory: array of strings,accepts wildcard * for any
  • source mandatory: array of strings,accepts wildcard * for any, one or more IPs and IP ranges (comma separated)

Response parameters

Element

Type

Description

riskprofile

String

Risk profile used for risk calculation

risksIdToData Map

Maps between risk internal ID (integer) and risk data

assessment String Risk assessment

code:

String risk code
description String Description of risk
details String Details
level String

Risk severity level:

  • High : String
  • Susp_High: String (Suspected high risks)
  • Medium: String
  • Low: String
remedy String Recommended remediation steps to fix the risk
trafficIdToRisksIds Map

Maps between provided ID (sequence ID, if not provided) and found risk internal IDs

  • See in response example below:
    Request includes traffic ID 100 and 101

  • The API found two risks for 100: risk internal ID 1 and 3

  • The API found two risks for 101: risk internal ID 2 and 4

Response:

Code

Description

200

Operation completed successfully

400 Bad request

401

Unauthorized

500 Internal server error

Request body examples in JSON Format

{

"traffic": [

{

"id" : "100",

"destination": ["1.2.3.4"],

"service": ["*"],

"source": ["10.1.1.1,2.2.2.2"]

} ,

{

"id" : "101",

"destination": ["10.1.1.1"],

"service": ["tcp/22" ],

"source": ["1.2.3.4"]

}

]

}

Response example in JSON Format

Copy
{
  "riskProfile": "Standard",
  "risksIdToData": {
    "1": {
      "code": "I01",
      "description": "\"Any\" service can enter your network",
      "level": "High",
      "assessment": "Your network is accessible from the Outside using the * (\"Any\") service. q_srv_Outside_Inside:*  Number of Outside IP addresses that have access: 1  Number of exposed Inside addresses: 1  Allowing \"Any\" service to enter your network is extremely risky since the \"Any\" service includes many vulnerable services. This is risky even if the traffic is only allowed from business partners or through VPNs (like SecuRemote clients): a remote laptop connecting through a VPN could easily infect your network with a worm or virus.",
      "remedy": "Review all the rules that allow inbound traffic with the * service, and limit them to those services you actually require. Consider quarantining VPN traffic in a DMZ.",
      "details": "Allowing the \"Any\" service to enter your network is extremely risky since the \"Any\" service includes many vulnerable services. This is risky even if the traffic is only allowed from business partners or through VPNs (like SecuRemote clients): a remote laptop connecting through a VPN could easily infect your network with a worm or virus."
    },
    "2": {
      "code": "O06",
      "description": "UDP on all ports can exit your network",
      "level": "Susp_High",
      "assessment": "Machines on your network can access the Outside using UDP on all possible ports. q_srv_Inside_Outside:ALL_UDP  Number of Inside IP addresses that have access: 1  Number of reachable Outside addresses: 1  Allowing TCP on all ports to exit your network is risky since this includes many vulnerable services. The largest threat is that of Trojan horses contacting their controllers, followed by unintended information leakage, and spreading of malicious code like viruses and worms. On Cisco firewalls, this risk is often the result of neglecting to specify a port number on an access-list or conduit statement: omitting the port number is interpreted as \"all ports\".",
      "remedy": "Review all the rules that allow outbound traffic with UDP on all ports, and limit them to those services you actually require. On Cisco firewalls, always specify the port numbers on access-list and conduit statements.",
      "details": "Allowing UDP on all ports to exit your network is extremely risky since this includes many vulnerable services. The largest threat is that of Trojan horses contacting their controllers, followed by unintended information leakage, and spreading of malicious code like viruses and worms. On Cisco firewalls, this risk is often the result of neglecting to specify a port number on an access-list or conduit statement: omitting the port number is interpreted as \"all ports\"."
    },
    "3": {
      "code": "I25",
      "description": "HTTP/HTTPS can enter your network",
      "level": "Susp_High",
      "assessment": "The total number of rules that contributed to this risk item is 1.  http and/or https are allowed to cross from the Outside into your internal network segments. q_srv_Outside_Inside  Number of Outside IP addresses that have access: 1  Number of exposed Inside addresses: 1   Normally, servers from the outside should not be able to access your internal network segments using the http or https services. Many sensitive machines provide a web interface: These include e-mail servers, printers, phone switches, routers, and firewalls. Furthermore, many vulnerabilities have been found in web server software. Allowing access from the Outside to these web interfaces is risky, since a compromised or infected server in the outside could cause wide-spread damage to your infrastructure.",
      "remedy": "Review the rules that allow http or https access from the Outside and eliminate them. If you need to transfer information from the internal network segments to servers in the outside, consider using a \"push\"-based solution (e.g., via ssh or ftp), which is initiated by the internal machines.",
      "details": "Letting the HTTP or HTTPS services reach machines that are not hardened web servers is risky. Many sensitive machines provide a web interface: These include e-mail servers, printers, phone switches, routers, and firewalls. Furthermore, many vulnerabilities have been found in web server software. Therefore, HTTP/HTTPS access, from the outside, should be eliminated."
    },
    "4": {
      "code": "R08",
      "description": "\"Allow Any service\" rules",
      "level": "Medium",
      "assessment": "Some of the rules are of the form  From <My Source> to <My Destination> with service Any : PASS [GW_mock_gw_2]  These are probably more open than is necessary. Allowing all services allows many services that are known to be risky, most of which you probably do not use in your business.",
      "remedy": "Review these rules, determine which services are actually required, and modify the rules according to the narrowest actual security needs.",
      "details": "Rules of the form From <My Source> to <My Destination> with service Any : PASS Are usually more open than is necessary. Allowing all services allows many services that are known to be risky, most of which you probably do not use in your business."
    }
  },
  "trafficIdToRisksIds": {
    "100": [
      1,
      3
    ],
    "101": [
      2,
      4
    ]
  }